@sreichel -Thank you for your work on this PR and for your kind words. However, I have some concerns and suggestions based on our previous implementations (PR #4239 and #4969) and on practical usability:

1. The current message is incomplete, as it does not specify exactly where the page is used. Using "Store View" in the message is not informative (and takes precious space), especially since multiple store views can have the same name. My approach displays the logical combination with a defined lord, such as "Default Config, Madison Website, Madison Website > French", making it much easier for users to quickly identify and change the relevant scope immediately (e.g. Store View: French vs Madison Island > French)

2. When changing strictly the URL key, Status, or Delete, there should always be two mandatory messages displayed. First, a warning stating that the action cannot be performed and showing the reason (a short phrase). Second, an informational message explaining concretely where is the place the user can make the change (including the link to Web > Default Pages). If other allowed data was changed, a third success message should be displayed to confirm that those changes were saved (not the one existing which creates confusion and says the page was saved - only the unrestricted fields were salved).

3. Based on our previous discussions and the changes already implemented, this PR should not only address the message shown when deleting a page, but also comprehensively cover all three scenarios: changing the URL Key, updating the Status, and deleting the page.

For the info message displaying where the page is used, I can drop the attempt to build a grammatically correct English sentence (method _joinWithCommaAnd in PR #4969).

I believe these adjustments are crucial for a better user experience, especially in multi-store setups but this PR forces me to close my previous work, even though it could be easily adapted to incorporate these suggestions and best practices.

The current message is incomplete

All is done here, can you make suggestions to the code?

    public static function getScopeInfoFromConfigScope(string $scope, string $scopeId): string
    {
        return match ($scope) {
            Mage_Adminhtml_Block_System_Config_Form::SCOPE_DEFAULT => Mage::helper('cms')->__('Default Config'),
            Mage_Adminhtml_Block_System_Config_Form::SCOPE_WEBSITES => sprintf(
                '%s "%s"',
                Mage::helper('cms')->__('Website'),
                Mage::app()->getWebsite($scopeId)->getName(),
            ),
            Mage_Adminhtml_Block_System_Config_Form::SCOPE_STORES => sprintf(
                '%s "%s"',
                Mage::helper('cms')->__('Store View'),
                Mage::app()->getStore($scopeId)->getName(),
            ),
        };
    }

this PR should not only address the message shown

This PR is ONLY for the message :P

Changes in logic please in another PR.

This is the current implementation in OpenMage. We can immediately notice that the message does not indicate where exactly the page is being used. The entire scope configuration list must be searched until it is found.

This is my implementation. The message clearly indicates where the page is being used. Furthermore, since it could be used in many places, I avoided using “Website” and “Store View” labels to save space. Moreover, the list of locations in parentheses follows a logical order — it fully traverses the tree, for example: Main Website, Main Website > French. If there are multiple stores, they will be listed in their respective order, making it even easier to find. In addition, I point the administrator to the exact location in the Backend where he can edit the scopes.

This is your implementation. It can be seen that you borrowed my idea of showing the scopes where the page is used, but the display is far from optimal — the usage of the words “Store View” and “Website” takes space, and I cannot tell at a glance where I should go (Stores and Websites are not listed in a logical order). In addition, there is no link to direct the administrator to edit the configuration; in my opinion, this is a useful feature.

In conclusion, thank you for taking the time to implement this PR. As I had already been working on a PR for the same functionality and shared my approach earlier, which includes more features, it would have been more constructive to coordinate rather than opening a separate PR and moving in a different direction.

Out of respect for you, I will refrain from reviewing further implementations and, more broadly, from contributing to anything related to the usage of pages in Default Pages. You are free to implement your approach. I will focus on improving my own version as a separate extension, ensuring it does not interfere with the core code and avoiding any conflicting discussions on this topic.

I hope you take all my feedback regarding this issue into consideration, with the request that you see it through to the end. I will focus my attention on other issues in OpenMage. Thank you for your understanding.

In a few words, lets change the wording. I asked for suggestions. Link to config is fine too.

This PR was to avoid working on duplicated functionality for getting usage in config.

?

If you appreciate a honest opinion, I don't like the sequence for ... for .... It sounds like hell.

Here are a better approach:

• This page cannot be deleted/disabled. It is used for configuring the following Default Pages: ...
• You cannot delete/disable this page. It is used to configure the following Default Pages: ...
• You cannot delete/disable this page, as it is used to configure ...

For the first two I would put the link on the Default Pages. It clearly indicates where the changes will take place.

https://github.com/search?q=repo%3AOpenMage%2Fmagento-lts+%22it+is+used+for%22&type=code

PLEAAAASE 😢 ^^

Sorry I have to come back. The sentences you gave as examples contain only one "for", while in this PR you are using two "for". In English sounds like hell.

You cannot disable this page as it is used for configuration for

That's why I offered you alternatives...

@addison74 changed wording. Any suggestions?

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@addison74 i'll merge.

Please dont get me wrong, but changing simple wording also takes a lot of time.

• change string in code
• change string in translation
• maybe change string in tests (unit/cypress)

... and ...

• stop work, change branch
• merge current branch
• fix conficts
• ... again and again

Please do not explain what you want to see, please activly help with code suggestions or commits.

I try my best, but there are thousends thing to to do. To speed up things gimme some time.